Skip to content

Add admin-gated Release workflow - #610

Open
MaddyMicrosoft wants to merge 8 commits into
masterfrom
ci/automate-release
Open

Add admin-gated Release workflow#610
MaddyMicrosoft wants to merge 8 commits into
masterfrom
ci/automate-release

Conversation

@MaddyMicrosoft

@MaddyMicrosoft MaddyMicrosoft commented Aug 16, 2026

Copy link
Copy Markdown
Member

Summary

Adds two admin-gated, manually-dispatched workflows that automate the Azure Login release runbook: release.yml (cut a release) and rollback.yml (undo a bad one).

Release workflow

Reproduces the release process end to end from a single dispatch:

  • Build from the chosen ref, commit the built lib/ to a new releases/<version> branch, tag <version> on that commit, force-move the major tag (e.g. v3), and publish a GitHub Release.
  • Node version is read from the ref's own action.yml, so each major builds with its intended toolchain (v2 → node20, v3 → node24).
  • ref input (default master) supports back-major releases: branch a hotfix off the latest release tag (git checkout -b hotfix/v2.3.2 v2.3.1) and release from it. Allowlisted to master or hotfix/* only.
  • No explicit latest handling: gh release create lets GitHub auto-mark the highest-version release as "Latest", so a v2 hotfix never steals the badge from v3.

Rollback workflow

Re-points the major tag back to a known-good, already-published version (the fast consumer-facing fix), mirroring the manual runbook:

  • Verifies the target tag exists and contains both built entry points (lib/main/index.js and lib/cleanup/index.js) before moving the major tag, so it can never point consumers at unbuilt code.
  • Does not delete the bad tag/branch/release (someone may have pinned the exact version) and does not touch Release objects — it only moves the major tag.

Admin gating (both workflows)

Enforced two ways:

  1. environment: release, which pauses the run until a required reviewer (admin) approves. This must be configured with required reviewers before first use.
  2. An "Ensure triggered by an admin" step that fails fast for non-admins.

Both share a release concurrency group so a release and a rollback can never race on the same major tag. Actions are pinned to @v6, matching the rest of the repo.

Notes

  • Guards run before the approval pause: admin check, version format (vX.Y.Z), ref allowlist, and version-is-new (tag/branch must not already exist).
  • Requires the release environment to exist with required reviewers; the workflows are inert-but-safe until it is configured.

MaddyMicrosoft and others added 2 commits August 17, 2026 09:04
Reproduces the Azure Login Action release runbook as a manually
dispatched workflow: checkout master, build, test, commit the built
lib/ to a releases/vX.Y.Z branch, tag that commit, force-move the major
tag (e.g. v3), and publish a GitHub Release.

Admin-only is enforced two ways:
- environment: release, which pauses the run until a required reviewer
  (admin) approves. This is the primary gate and must be configured with
  required reviewers in repo settings before the first real release.
- an 'Ensure triggered by an admin' step that fails fast for non-admins.

Actions are pinned to @v6 to match the rest of the repo.
Undo a bad release by re-pointing the major tag (e.g. v3) back to a
known-good, already-published version tag. This is the fast
consumer-facing fix: anyone on azure/login@v3 recovers immediately.

- Admin-gated the same two ways as release.yml: environment: release
  approval plus an actor-admin check.
- Shares the 'release' concurrency group so a rollback can never race an
  in-flight release (both push the same major tag).
- Verifies the target tag exists and carries both built entry points
  (lib/main/index.js and lib/cleanup/index.js) before moving the major
  tag, so it can never point consumers at unbuilt code.
- Optionally resets the 'Latest' release badge; tolerates a missing
  Release object so a cosmetic badge failure never fails a successful
  tag rollback.
- Does NOT delete the bad tag/branch/release (someone may have pinned the
  exact version); left as a deliberate manual step.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@MaddyMicrosoft
MaddyMicrosoft marked this pull request as ready for review August 18, 2026 01:50
MaddyMicrosoft and others added 2 commits August 18, 2026 03:13
The allowlist previously accepted releases/v2 for v2 maintenance, but
releases/v2 is a stale early-v2 snapshot that does not contain the later
v2 releases (v2.3.0, v2.3.1, ...). Releasing from it would ship old code.

The latest v2 source lives in the newest v2 release tag. To cut a
back-major release, branch a hotfix off that tag
(git checkout -b hotfix/v2.3.2 v2.3.1), apply the fix, and release from
the hotfix/* branch. Drop releases/v2 from the allowlist so it can no
longer be selected by mistake.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
gh release create defaults to marking the highest-version release as
"Latest", so a back-major release (e.g. a v2 hotfix) never steals the
badge from the current major on its own. The explicit latest controls
were therefore redundant, and rollback's badge edit conflicted with
immutable releases.

- release.yml: remove the latest input, the back-major latest guard, and
  the --latest flag on gh release create.
- rollback.yml: remove the set_latest input and the gh release edit
  --latest badge step. Rollback now does only the major-tag move (matching
  the original runbook) plus the admin gate and built-artifact checks.

The "Latest" badge is display-only and never affects what azure/login@vN
resolves to, so this is behaviourally safe.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants